An enterprise's data is its lifeblood. Lose its data, and the enterprise is likely to fail. Therefore, it is imperative for a company to maintain a copy of its data at some remote site that is impervious to a catastrophe that might cause the primary copy of the data to be lost.
A major decision that a company must make is how much data loss it can tolerate following not only a catastrophe, but also following an ordinary failure of its primary processing facility. This is known as the company's Recovery Point Objective, or RPO. Classic backup techniques support RPOs measured in hours or days—this is the amount of data that might be lost following the failure of the processing system. Data replication technology can reduce this to seconds (asynchronous replication) or even to zero (synchronous replication).
However, simply being able to recover most or all of a company's data does it no good if it cannot continue to provide application services to its users. The amount of time that a company can afford to deny service to its users is its Recovery Time Objective, or RTO. Again, classic techniques provide recovery times measured in hours or days. Clusters and unidirectional data replication can reduce recovery time to several minutes.
If an application cannot be down at all or needs to come back online quickly (for the users attached to the failed node) without causing undue hardship, active/active systems can provide recovery times measured in seconds or subseconds. In an active/active system, multiple geographically-distributed nodes cooperate in a common application, executing transactions against local copies of the application database. Should a node fail, it is only necessary to reroute users or transactions to one or more surviving nodes. This can be accomplished in seconds or subseconds. It is important that the database copies be kept in close or exact synchronism. This can only be done by replicating in real time changes made to one database copy to the other database copies in the application network.
Consequently, data replication plays an important role if RPOs and RTOs are to be measured in seconds. The advantage of synchronous replication is that it avoids any data loss following a node failure and therefore supports zero RPOs. Active/active systems can reduce RTO to near zero, or make it so fast that the users don't even notice.
However, synchronous replication brings with it one serious issue; and that is application latency. The transaction response times of applications are extended because an application must wait for its transaction data to be committed (or at least safe stored) across the network. As the distance between nodes becomes greater, communication latency (the round trip time of the communication channel) can add greatly to transaction response time.
This is particularly true for applications that replicate synchronously using network transactions or distributed lock management since each individual operation must flow across the communication network before the next operation is issued. Transaction response time becomes dependent not only upon the distance separating the nodes but also on the size of the transactions. As a consequence, such systems must limit the distance between processing nodes in order to achieve acceptable performance. These systems are typically limited to campus environments or perhaps metropolitan environments. As a result, their abilities to withstand broader disasters such as earthquakes, hurricanes, floods, or terrorist attacks are severely compromised.
The use of coordinated commit technology discussed in U.S. Pat. No. 6,662,196 (Holenstein et al.) and U.S. Pat. No. 7,103,586 (Holenstein et al.), both of which are incorporated by reference in their entirety herein, solves the latency problem. An application waits only one replication channel latency time to ensure that all remote nodes are prepared to commit the transaction. Therefore, application latency is not affected by transaction size and is only marginally affected by internodal distances. Nodes handling large transactions can be thousands of miles apart and can still provide good response times in a synchronous distributed environment.
There are prior art replication systems that operate in an asynchronous mode, and replication systems that operate in a synchronous mode. Also, as discussed in U.S. Pat. No. 5,724,556 (Souder et al.), U.S. Pat. No. 5,937,414 (Souder et al.), and U.S. Pat. No. 6,532,479 (Souder et al.), there are replication systems that can switch between the two, for example when synchronous replication cannot occur due to a network fault. However, these replication systems do not operate in both asynchronous and synchronous replication modes at the same time in the same direction (i.e., from originating to target node). Instead, they force an all-or-nothing switch from one mode to the other.
Additionally, there are various approaches for allocating transactions and their underlying transaction steps or operations when operating in either the asynchronous or synchronous replication modes. These approaches include allocation on an object-by-object basis for asynchronous replication and allocation on a transaction-by-transaction basis for synchronous replication. The two approaches are not used at the same time, and object-by-object allocation is generally not used with synchronous replication, and transaction-by-transaction allocation is generally not used with asynchronous replication.
As mentioned above, switching from one replication mode to another with prior art data replication engines is on an all-or-nothing basis, which usually requires quiescing (from making database changes) the application and denying service to its users while the transition occurs. What is needed are methods that allow the replication engine to switch from one mode to the other and from one allocation approach to the other without dramatically affecting the application and denying service to its users, thereby maintaining desirable availability, latency, and recoverability properties. Additionally, by allowing the replication modes and allocation approaches to be combined and used at the same time, the replication system can provide additional capabilities for data management and transaction replay not available in the current methods.